The World of Computer Software/The World of Computer Software.iso/jpegfaq.txt

Text File | 1993-01-06 | 35.0 KB | 648 lines

=========================================================================
Xref: news.acns.nwu.edu comp.graphics:14833 alt.binaries.pictures.d:4783 alt.graphics.pixutils:3323 alt.binaries.pictures.erotica.d:5445 news.answers:1966
Path: uicvm.uic.edu!news.acns.nwu.edu!zaphod.mps.ohio-state.edu!
 uakari.primate.wisc.edu!ames!agate!stanford.edu!rutgers!rochester!cantaloupe.srv.cs.cmu.edu!tgl
From: [e-mail] (Tom Lane)
Newsgroups: comp.graphics,alt.binaries.pictures.d,alt.graphics.pixutils,alt.binaries.pictures.erotica.d,news.answers
Subject: JPEG image compression: Frequently Asked Questions
Summary: Useful info about JPEG (JPG) image files and programs
Keywords: JPEG, image compression, FAQ
Message-ID: <[e-mail]>
Date: 29 Jun 92 16:11:15 GMT
Expires: Mon, 27 Jul 92 16:11:04 GMT
Reply-To: [e-mail]
Followup-To: alt.binaries.pictures.d
Organization: School of Computer Science, Carnegie Mellon
Lines: 626
Approved: [e-mail]
Supersedes: <[e-mail]>
Nntp-Posting-Host: g.gp.cs.cmu.edu
Originator: [e-mail]

Archive-name: jpeg-faq
Last-modified: 29 June 1992

This FAQ article discusses JPEG image compression.  Suggestions for
additions and clarifications are welcome.

This article includes the following sections:

1)  What is JPEG?
2)  Why use JPEG?
3)  How well does it work?
4)  What are good "quality" settings for JPEG?
5)  When should I use JPEG, and when should I stick with GIF?
6)  Where can I get JPEG software?
    6A) "canned" software, viewers, etc.
    6B) source code
7)  What's all this hoopla about color quantization?
8)  How does JPEG work?
9)  What about lossless JPEG?
10)  Why all the argument about file formats?
11)  And what about arithmetic coding?
12)  Does loss accumulate with repeated compression/decompression?

----------


1)  What is JPEG?

JPEG (pronounced "jay-peg") is a standardized image compression mechanism.
JPEG stands for Joint Photographic Experts Group, the original name of the
committee that wrote the standard.  JPEG is designed for compressing either
full-color or gray-scale digital images of "natural", real-world scenes.
It does not work as well on non-realistic images, such as cartoons or line
drawings.

JPEG does not handle black-and-white (1-bit-per-pixel) images, nor does it
handle motion picture compression.  Standards for compressing those types
of images are being worked on by other committees, named JBIG and MPEG
respectively.

JPEG is "lossy", meaning that the image you get out of decompression isn't
quite identical to what you originally put in.  The algorithm achieves much
of its compression by exploiting known limitations of the human eye, notably
the fact that small color details aren't perceived as well as small details
of light-and-dark.  Thus, JPEG is intended for compressing images that will
be looked at by humans.  If you plan to machine-analyze your images, the
small errors introduced by JPEG may be a problem for you, even if they are
invisible to the eye.

A useful property of JPEG is that the degree of lossiness can be varied by
adjusting compression parameters.  This means that the image maker can trade
off file size against output image quality.  You can make *extremely* small
files if you don't mind poor quality; this is useful for indexing image
archives, making thumbnail views or icons, etc. etc.  Conversely, if you
aren't happy with the output quality at the default compression setting, you
can jack up the quality until you are satisfied, and accept lesser compression.


2)  Why use JPEG?

There are two good reasons: to make your image files smaller, and to store
24-bit-per-pixel color data instead of 8-bit-per-pixel data.

Making image files smaller is a big win for transmitting files across
networks and for archiving libraries of images.  Being able to compress a
2 Mbyte full-color file down to 100 Kbytes or so makes a big difference in
disk space and transmission time!  (If you are comparing GIF and JPEG, the
size ratio is more like four to one.  More details below.)

Unless your viewing software supports JPEG directly, you'll have to convert
JPEG to some other format for viewing or manipulating images.  Even with a
JPEG-capable viewer, it takes longer to decode and view a JPEG image than to
view an image of a simpler format (GIF, for instance).  Thus, using JPEG is
essentially a time/space tradeoff: you give up some time in order to store
or transmit an image more cheaply.

It's worth noting that when network or phone transmission is involved, the
time savings from transferring a shorter file can be much greater than the
extra time to decompress the file.  I'll let you do the arithmetic yourself.

The other reason why JPEG will gradually replace GIF as the standard Usenet
posting format is that JPEG can store full color information: 24 bits/pixel
(16 million colors) instead of 8 or less (256 or fewer colors).  If you have
only 8-bit display hardware then this may not seem like much of an advantage
to you.  Within a couple of years, though, 8-bit GIF will look as obsolete as
black-and-white MacPaint format does today.  Furthermore, for reasons detailed
in section 7, JPEG is far more useful than GIF for exchanging images among
people with widely varying color display hardware.  Hence JPEG is considerably
more appropriate than GIF for use as a Usenet posting standard.


3)  How well does it work?

Pretty darn well.  Here are some sample file sizes for an image I have handy,
a 727x525 full-color image of a ship in a harbor.  The first three files are
for comparison purposes; the rest were created with the free JPEG software
described in section 6B.

File       Size in bytes                Comments

ship.ppm        1145040  Original file in PPM format (no compression;
                         3 bytes per pixel plus a few bytes overhead)
ship.ppm.Z       963829  PPM file passed through Unix compress
                         compress doesn't accomplish a lot, you'll note.
ship.gif         240438  Converted to GIF with ppmquant -fs 256 | ppmtogif
                         Most of the savings is the result of losing color
                         info: GIF saves 8 bits/pixel, not 24.  (See sec. 7.)

ship.jpg95       155622  cjpeg -Q 95    (highest useful quality setting)
                         This is indistinguishable from the 24-bit original,
                         at least to my nonprofessional eyeballs.
ship.jpg75        58009  cjpeg -Q 75    (default setting)
                         You have to look mighty darn close to distinguish this
                         from the original, even with both on-screen at once.
ship.jpg50        38406  cjpeg -Q 50
                         This has slight defects; if you know what to look
                         for, you could tell it's been JPEGed without seeing
                         the original.  Still as good image quality as many
                         recent postings in Usenet pictures groups.
ship.jpg25        25192  cjpeg -Q 25
                         JPEG's characteristic "blockiness" becomes apparent
                         at this setting (djpeg -b helps some).  Still, I've
                         seen plenty of Usenet postings that were of poorer
                         image quality than this.
ship.jpg5o         6587  cjpeg -Q 5 -o  (-o reduces table overhead)
                         Blocky, but perfectly satisfactory for preview or
                         indexing purposes.  Note that this file is TINY:
                         the compression ratio from the original is 173:1 !

In this case JPEG can make a file that's a factor of four or five smaller
than a GIF of comparable quality (the -Q 75 file is every bit as good as the
GIF, better if you have a full-color display).  This seems to be a typical
ratio for real-world scenes.


4)  What are good "quality" settings for JPEG?

(Note: the -Q settings discussed in this article apply to the free JPEG
software described in section 6B.  Other JPEG implementations, such as Image
Alchemy, may use a completely different quality scale.)

The name of the game in using JPEG is to pick the lowest quality setting
(smallest file size) that decompresses into an image indistinguishable from
the original.  This setting will vary from one image to another and from one
observer to another, but here are some rules of thumb.

The default quality setting (-Q 75) is very often the best choice.  This
setting is about the lowest you can go without expecting to see defects in a
typical image.  Try -Q 75 first; if you see defects, then go up.  Except for
experimental purposes, never go above -Q 95; saying -Q 100 will produce a
file two or three times as large as -Q 95, but of hardly any better quality.

If the image was less than perfect quality to begin with, you might be able to
go down to -Q 50 without objectionable degradation.  On the other hand, you
might need to go to a HIGHER quality setting to avoid further degradation.
The second case seems to apply most of the time when converting GIFs to JPEG.
The default -Q 75 is about right for compressing 24-bit images, but -Q 85 to
95 is usually better for converting GIFs (see next section for more info).

If you want a very small file (say for preview or indexing purposes) and are
prepared to tolerate large defects, a -Q setting in the range of 5 to 10 is
about right.  -Q 2 or so may be amusing as "op art".

Another recommendation: when you are making a final version of an image for
posting on Usenet or archiving, specify "-o" to cjpeg.  This will make the
file a little smaller without affecting image quality; it will take longer
to do the compression, but not any longer to decompress.


5)  When should I use JPEG, and when should I stick with GIF?

As a rule of thumb, JPEG is superior to GIF for storing full-color or
gray-scale images of "realistic" scenes; that means scanned photographs and
similar material.  JPEG is superior even if you don't have 24-bit display
hardware, and it is a LOT superior if you do.  (See section 7 for details.)

GIF does significantly better on images with only a few distinct colors,
such as cartoons and line drawings.  In particular, large areas of pixels
that are all *exactly* the same color are compressed very efficiently indeed
by GIF.  JPEG can't squeeze these files as much as GIF does without
introducing visible defects.  This sort of image is best kept in GIF form.
(Incidentally, many people have developed an odd habit of putting a large
constant-color border around a GIF image.  This was nearly free in terms of
storage cost in GIF files.  It is NOT free in JPEG files.  Do yourself a
favor and don't add a border; let your viewer blank out unused screen area.
If you're converting a GIF to JPEG, crop off any border first.)

JPEG also has a hard time with very sharp edges: a row of pure-black pixels
adjacent to a row of pure-white pixels, for example.  Sharp edges tend to
come out blurred unless you use a very high quality setting.  Again, this
sort of thing is not found in scanned photographs, but it shows up fairly
often in GIF files: borders, overlaid text, etc.  The blurriness is
particularly objectionable with text that's only a few pixels high.
If you have a GIF with a lot of small-size overlaid text, don't JPEG it.

Computer-drawn images (ray-traced scenes, for instance) usually fall between
scanned images and cartoons in terms of complexity.  The more complex and
subtly rendered the image, the more likely that JPEG will do well on it.

If you have an existing library of GIF images, you may wonder whether you
should convert them to JPEG.  You will lose some image quality if you do.
(Section 7, which argues that JPEG image quality is superior to GIF, only
applies if both formats start from a full-color original.  If you start from
a GIF, you've already irretrievably lost a great deal of information; JPEG
can only make things worse.)  However, the disk space savings may justify
converting anyway.  This is a decision you'll have to make for yourself.
If you do convert a GIF library to JPEG, I recommend looking at each JPEG
to make sure you are happy with it before throwing away the corresponding
GIF; that will give you a chance to re-do the conversion with a higher
quality setting if necessary.

Experience to date suggests that large, high-quality GIFs are the best
candidates for conversion to JPEG.  They chew up the most storage so offer
the most potential savings, and they convert to JPEG with least degradation.
Don't waste your time converting any GIF much under 100 Kbytes.  Also, don't
expect JPEG files converted from GIFs to be as small as those created
directly from full-color originals.  To maintain image quality you may have
to let the converted files be as much as twice as big as straight-through
JPEG files would be (i.e., shoot for 1/2 or 1/3rd the size of the GIF file,
not 1/4th as shown in the earlier comparisons).  A -Q setting of 85 to 95
will minimize the additional degradation caused by converting a GIF to JPEG.


6)  Where can I get JPEG software?

6A) If you are looking for "canned" software, viewers, etc:

The first part of this list is system-specific programs that only run on one
kind of system.  If you don't see what you want for your machine, check out
the portable JPEG software described at the end of the list.

X Windows:

John Bradley's free XV (version 2.00 and up) is an excellent viewer for JPEG,
GIF, and other image formats.  It's available for FTP from export.lcs.mit.edu
or ftp.cis.upenn.edu.  The file is called 'xv-???.tar.Z' (where ??? is the
version number, currently 2.21) and is located in the 'contrib' directory on
export or the 'pub/xv' directory at upenn.  XV reduces all images to 8 bits
internally, which means it's not a real good choice if you have a 24-bit
display (you still get only 8-bit color).  Also, you shouldn't use XV to
convert full-color images to JPEG, because they'll get color-quantized first.

"xloadimage" is less featureful than XV, but it will do the right thing on
24-bit displays.  xloadimage is free and available from export.lcs.mit.edu,
file contrib/xloadimage.3.01.tar.Z.  Version 3.01 does not read JPEG files,
but it will read the PPM files put out by the free JPEG software described in
6B.  There is also a patched version called "xli" (see files xli.* in same
directory) that does read JPEG directly.  However, xli is a quick hack rather
than an official release; caveat user.

Another good choice for X Windows is John Cristy's free ImageMagick package,
also available from export, file contrib/ImageMagick.tar.Z.  The viewer
included in this package handles 24-bit displays correctly; for colormapped
displays, it does better (though slower) color quantization than XV or the
basic free JPEG software.

MS-DOS:

Currently there is only one usable JPEG viewer for plain MS-DOS (non-Windows);
that's Eric Praetzel's free DVPEG.  The current version, 1d, is available by
FTP from sunee.waterloo.edu, file pub/jpeg/viewers/dvpeg1d.zip.  This is a
prototype with a rather unpolished user interface, and it only supports
the most common super-VGA display cards, but hey, it's free.

If DVPEG doesn't work on your hardware, you'll need to use one of the
following conversion programs to convert JPEG to GIF, then view with your
favorite GIF viewer.

The Independent JPEG Group's free JPEG converters are FTPable from
wuarchive.wustl.edu (128.252.135.4), directory mirrors/msdos/graphics, file
jpeg3.zip (or jpeg3386.zip if you have a 386 and extended memory); also from
SIMTEL20 and its other mirror sites.  The same files were posted to
comp.binaries.ibm.pc (volume 18, issues 123-130) and should be available
from any c.b.i.p archive site.  These files are DOS compilations of the free
source code described in section 6B.

Handmade Software offers two rather pricy shareware programs: Image Alchemy
and GIF2JPG/JPG2GIF (contact [e-mail] for details).  The PC versions of
these programs are available for FTP from wuarchive.wustl.edu, directory
mirrors/msdos/graphics, files alchmy15.zip and gif2jpg5.zip; also from
SIMTEL20 and its other mirror sites.  GIF2JPG/JPG2GIF only perform JPEG<=>GIF
format conversion.  Image Alchemy converts files between these and many other
formats, and can also display images on some types of hardware.  The display
option is limited and not very high quality, so you'll still want a separate
viewer program.  (CAUTION: GIF2JPG produces a proprietary file format unless
you specify -j.  Be sure to use -j if you want to exchange JPEG files with
other Usenet users.  For that matter, it's not real clear that you should be
posting JPEG files made from GIFs; see section 5.)

In my biased opinion, the free JPEG software is a better choice than
GIF2JPG/JPG2GIF; it's faster, as good or better image quality, and free :-).
On the other hand, Image Alchemy may be worth its price, if you need the
additional conversion and image manipulation capabilities it provides.

Microsoft Windows:

There are a couple of shareware JPEG viewers available by FTP.  Look for
WinJPEG (current version is 1.1, available from wuarchive.wustl.edu:
mirrors/msdos/windows3/winjp110.zip; also at SIMTEL20 or any of its mirror
sites) or ColorView (current version is 0.97, wuarchive.wustl.edu:
mirrors/win3/desktop/cview097.zip).  WinJPEG seems to be a shade faster and
more robust than the current prototype version of ColorView, but they have
different features so you may want to try both.

At least two freeware Windows JPEG viewers are also undergoing beta test and
should be out shortly; watch this space...

The DOS conversion programs described above can be used inside a Windows
DOS window.

Macintosh:

Apple has released a free program called PictPixie (formerly known as
PictCompressor) that can convert the Usenet-standard JFIF JPEG format to and
from QuickTime's internal JPEG format.  PictPixie can also be used as a
viewer for JFIF, QuickTime JPEG, and GIF files.  You can get PictPixie from
ftp.apple.com, file dts/mac/quicktime/pictpixie.hqx.  You need both
QuickTime and 32-bit QuickDraw to run PictPixie (and therefore you must be
running System 6.0.7 or later).  You can get QuickTime from the same FTP
directory; I think 32-bit QuickDraw is an optional item on the System 6.0.7
disks.  PictPixie is considered a developer's tool; you may not care for its
user interface.  There is a simplified version of this program in the
QuickTime Starter Kit.

Another good choice is JPEGView, a free program for viewing both JFIF and
QuickTime JPEG files, as well as converting between the two formats.
The current version, 1.0, is much improved over the initial release (0.9).
Get it from sumex-aim.stanford.edu, file /info-mac/app/jpeg-view-10.hqx.
This program requires System 7 and QuickTime.  It doesn't do quite as much
as PictPixie, but it is fast and handier than PictPixie for skimming through
lots of images.

Storm Technology has released a free JPEG viewer called Picture Decompress.
This is generally inferior to PictPixie or JPEGView, but it will run without
System 7 or QuickTime, so you may be forced to use it on older systems.
You'll still need 32-bit QuickDraw, though.  This program can be FTPed from
sumex-aim.stanford.edu, file /info-mac/app/picture-decompress-201.hqx.  Make
sure you get version 2.0.1 or later; earlier versions are not compatible
with JFIF file format.  You'll also need a tool for adjusting file type
codes; you must set the type of a downloaded image file to 'JPEG' to allow
Picture Decompress to open it.

On 8-bit-color Macs, neither Picture Decompress nor JPEGView produce really
high quality displays, since they do quick-and-dirty color reduction (this
is not a problem if you are fortunate enough to have a 24-bit display).
I hear that PictPixie does better than the other two programs.  (The free
JPEG software, described later, does an even better job of reducing JPEG
images to 8-bit color.  Unfortunately, no one has gotten around to releasing
a precompiled version of the free software for Macintoshes.)

Amiga:

I'm told the shareware program HAMLab is about the best tool for viewing/
converting JPEG files.  This should be available from most big Amiga archive
sites.

Portable software for almost any system:

If none of the above fits your situation, you can obtain and compile the free
JPEG conversion software described in 6B.  You'll also need a viewer program.
If your display is 8 bits or less, any GIF viewer will do fine; if you have a
display with more color capability, try to find a viewer that can read Targa
or PPM 24-bit image files.

If you are not reasonably handy at configuring and installing portable C
programs, you may have some difficulty installing the free source code.
Steve Davis ([e-mail]) has volunteered to maintain an archive of
pre-built executable versions of the free JPEG code for various machines.
His FTP archive is at ftp.cis.ksu.edu (129.130.10.80); look under /pub/JPEG
to see what he currently has.  (The administrators of this system ask that
FTP traffic be limited to non-prime hours.)  This archive is not maintained
by the Independent JPEG Group, and files in it may not represent the latest
free source code.

There are numerous commercial JPEG offerings, with more popping up every
day.  I recommend that you not spend money on one of these unless you find
the available free or shareware software vastly too slow.  In that case,
purchase a hardware-assisted product.  Ask pointed questions about whether
the product complies with the final JPEG standard and about whether it can
handle the JFIF file format; many of the earliest commercial releases are
not and never will be compatible with anyone else's files.


6B) If you are looking for source code to work with:

Free, portable C code for JPEG compression is available from the Independent
JPEG Group, which I lead.  A package containing our source code,
documentation, and some small test files is available from several places.
The "official" archive site for this source code is ftp.uu.net (137.39.1.9
or 192.48.96.9).  Look under directory /graphics/jpeg; the current release
is jpegsrc.v3.tar.Z.  (This is a compressed TAR file; don't forget to
retrieve in binary mode.)  You can retrieve this file by FTP or UUCP.
Folks in Europe may find it easier to FTP from nic.funet.fi (see directory
pub/graphics/programs/jpeg).  The source code is also available on
CompuServe, in the GRAPHSUPPORT forum (GO PICS), library 10, as jpsrc3.zip.
If you have no FTP access, you can retrieve the source from your nearest
comp.sources.misc archive; version 3 appeared as issues 1-18 of volume 29.
(See the "How to find sources" FAQ article, which appears regularly in
news.answers, if you don't know how to retrieve comp.sources.misc postings.)

The free JPEG code provides conversion between JPEG "JFIF" format and image
files in GIF, PBMPLUS PPM/PGM, Utah RLE, and Truevision Targa file formats.
The core compression and decompression modules can easily be reused in other
programs, such as image viewers.  The package is highly portable; we have
tested it on many machines ranging from PCs to Crays.

We have released this software for both noncommercial and commercial use.
Companies are welcome to use it as the basis for JPEG-related products.
We do not ask a royalty, although we do ask for an acknowledgement in
product literature (see the README file in the distribution for details).
We hope to make this software industrial-quality --- although, as with
anything that's free, we offer no warranty and accept no liability.

The Independent JPEG Group is a volunteer organization; if you'd like to
contribute to improving our software, you are welcome to join.


7)  What's all this hoopla about color quantization?

Most people don't have full-color (24 bit per pixel) display hardware.
Typical display hardware stores 8 or fewer bits per pixel, so it can display
256 or fewer distinct colors at a time.  To display a full-color image, the
computer must map the image into an appropriate set of representative
colors.  This process is called "color quantization".

Clearly, color quantization is a lossy process.  It turns out that for most
images, the details of the color quantization algorithm have MUCH more impact
on the final image quality than do any errors introduced by JPEG (except at
the very lowest JPEG quality settings).

Since JPEG is inherently a full-color format, converting a JPEG image for
display on 8-bit-or-less hardware requires color quantization.  On the other
hand, a GIF image by definition has already been quantized to 256 or fewer
colors.  For purposes of Usenet picture distribution, GIF has the advantage
that the sender precomputes the color quantization, so recipients don't have
to.  This is also the *disadvantage* of GIF: you're stuck with the sender's
quantization.  If the sender quantized to a different number of colors than
what you can display, you have to re-quantize, resulting in much poorer
image quality than if you had quantized once from a full-color image.
Furthermore, if the sender didn't use a high-quality color quantization
algorithm, you're out of luck.

For this reason, JPEG offers the promise of significantly better image quality
for all users whose machines don't match the sender's display hardware.
JPEG's full color image can be quantized to precisely match the user's display
hardware.  Furthermore, you will be able to take advantage of future
improvements in quantization algorithms (there is a lot of active research in
this area), or purchase better display hardware, to get a better view of JPEG
images you already have.  With a GIF, you're stuck forevermore with what was
sent.

It's also worth mentioning that many GIF-viewing programs include rather
shoddy quantization routines.  If you view a 256-color GIF on a 16-color EGA
display, for example, you are probably getting a much worse image than you
need to.  This is partly an inevitable consequence of doing two color
quantizations (one to create the GIF, one to display it), but often it's
also due to sloppiness.  JPEG conversion programs will be forced to use
high quality quantizers in order to get acceptable results at all, and in
normal use they will quantize directly to the number of colors to be
displayed.  Thus, JPEG is likely to provide better results than the average
GIF program for low-color-resolution displays as well as high-resolution ones!


8)  How does JPEG work?

The buzz-words to know are chrominance subsampling, discrete cosine
transforms, coefficient quantization, and Huffman or arithmetic entropy
coding.  This article's long enough already, so I'm not going to say more
than that.  For a good technical introduction, see:
        Wallace, Gregory K.  "The JPEG Still Picture Compression Standard",
        Communications of the ACM, April 1991 (vol. 34 no. 4), pp. 30-44.
(Adjacent articles in that issue discuss MPEG motion picture compression,
applications of JPEG, and related topics.)  If you don't have the CACM issue
handy, a PostScript file containing a revised version of this article is
available at ftp.uu.net, graphics/jpeg/wallace.ps.Z.  The file (actually a
preprint for an article to appear in IEEE Trans. Consum. Elect.) omits the
sample images that appeared in CACM, but it includes corrections and some
added material.  Note: the Wallace article is copyright ACM and IEEE, and
it may not be used for commercial purposes.


9)  What about lossless JPEG?

There's a great deal of confusion on this subject.  The JPEG committee did
define a truly lossless compression algorithm, i.e., one that guarantees the
final output is bit-for-bit identical to the original input.  However, this
lossless mode has almost nothing in common with the regular, lossy JPEG
algorithm.  At present, very few implementations of lossless JPEG exist,
and all of them are commercial.

Saying "-Q 100" to the free JPEG software DOES NOT get you a lossless image.
What it does get rid of is deliberate information loss in the coefficient
quantization step.  There is still a good deal of information loss in the
color subsampling step.  (There should be a command line switch to disable
subsampling, but as of today, there isn't one.)

Even with both quantization and subsampling turned off, the regular JPEG
algorithm is not lossless, because it is subject to roundoff errors in
various calculations.  The maximum error is a few counts in any one pixel
value; it's highly unlikely that this could be perceived by the human eye,
but it might be a concern if you are doing machine processing of an image.

At this minimum-loss setting, regular JPEG produces files that are perhaps
half the size of an uncompressed 24-bit-per-pixel image.  True lossless JPEG
provides roughly the same amount of compression, but it guarantees
bit-for-bit accuracy.

If you have an application requiring lossless storage of images with less
than 6 bits per pixel (per color component), you may want to look into the
JBIG bilevel image compression standard.  This performs better than JPEG
lossless on such images.  JPEG lossless is superior to JBIG on images with
8 or more bits per pixel; furthermore, it is public domain, while the JBIG
techniques are heavily covered by patents.


10)  Why all the argument about file formats?

Strictly speaking, JPEG refers only to a family of compression algorithms;
it does *not* refer to a specific image file format.  The JPEG committee was
prevented from defining a file format by turf wars within the international
standards organizations.

Since we can't actually exchange images with anyone else unless we agree on
a common file format, this leaves us with a problem.  In the absence of
official standards, a number of JPEG program writers have just gone off to
"do their own thing", and as a result their programs aren't compatible with
anybody else's.

The closest thing we have to a de-facto standard JPEG format is some work
that's been coordinated by people at C-Cube Microsystems.  They have defined
two JPEG-based file formats:
  * JFIF (JPEG File Interchange Format), a "low-end" format that transports
    pixels and not much else.
  * TIFF/JPEG, aka TIFF 6.0, an extension of the Aldus TIFF format.  TIFF is
    a "high-end" format that will let you record just about everything you
    ever wanted to know about an image, and a lot more besides :-).  TIFF is
    a lot more complex than JFIF, and may well prove less transportable,
    because different vendors have historically implemented slightly different
    and incompatible subsets of TIFF.  It's not likely that adding JPEG to the
    mix will do anything to improve this situation.
Both of these formats were developed with input from all the major vendors
of JPEG-related products; it's reasonably likely that future commercial
products will adhere to one or both standards.

A particular case that people may be interested in is Apple's QuickTime
software for the Macintosh.  QuickTime uses a JFIF-compatible format wrapped
inside the Mac-specific PICT structure.  Conversion between JFIF and
QuickTime JPEG is pretty straightforward; in fact Apple has released a
utility program for the purpose (see PictPixie in section 6A).

I believe that Usenet should adopt JFIF as the replacement for GIF in
picture postings.  JFIF is simpler than TIFF and is available now; the
TIFF/JPEG spec is still not officially adopted.  Even when TIFF/JPEG is
available, the JFIF format is likely to be a widely supported "lowest
common denominator"; TIFF/JPEG files may never be as transportable.


11)  And what about arithmetic coding?

The JPEG spec defines two different "back end" modules for the final output
of compressed data: either Huffman coding or arithmetic coding is allowed.
The choice has no impact on image quality, but arithmetic coding usually
produces a smaller compressed file.  On typical images, arithmetic coding
produces a file 5 or 10 percent smaller than Huffman coding.  (All the
file-size numbers previously cited are for Huffman coding.)

Unfortunately, the particular variant of arithmetic coding specified by the
JPEG standard is subject to patents owned by IBM, AT&T, and Mitsubishi.
Thus *you cannot legally use arithmetic coding* unless you obtain licenses
from these companies.  (The "fair use" doctrine allows people to implement
and test the algorithm, but actually storing any images with it is dubious
at best.)

At least in the short run, I recommend that people not worry about
arithmetic coding; the space savings isn't great enough to justify the
potential legal hassles.  In particular, arithmetic coding *should not*
be used for any images to be exchanged on Usenet.

There is some small chance that the legal situation may change in the
future.  Stay tuned for further details.


12)  Does loss accumulate with repeated compression/decompression?

It would be nice if, having compressed an image with JPEG, you could
decompress it, manipulate it (crop off a border, say), and recompress it
without any further image degradation beyond what you lost initially.
Unfortunately THIS IS NOT THE CASE.  In general, recompressing an altered
image loses more information, though usually not as much as was lost the
first time around.

The next best thing would be that if you decompress an image and recompress
it *without changing it* then there is no further loss, i.e., you get an
identical JPEG file.  Even this is not true; at least, not with the current
free JPEG software.  It's essentially a problem of accumulation of roundoff
error.  If you repeatedly compress and decompress, the image will eventually
degrade to where you can see visible changes from the first-generation
output.  (It usually takes many such cycles to get visible change.)
One of the things on our to-do list is to see if accumulation of error can
be avoided or limited, but I am not optimistic about it.

In any case, the most that could possibly be guaranteed would be that
compressing the unmodified full-color output of djpeg, at the original
quality setting, would introduce no further loss.  Even such simple changes
as cropping off a border could cause further roundoff-error degradation.
(If you're wondering why, it's because the pixel-block boundaries move.
If you cropped off only multiples of 16 pixels, you might be safe, but
that's a mighty limited capability!)

The bottom line is that JPEG is a useful format for archival storage and
transmission of images, but you don't want to use it as an intermediate
format for sequences of image manipulation steps.  Use a lossless format
(PPM, RLE, TIFF, etc) while working on the image, then JPEG it when you are
ready to file it away.  Aside from avoiding degradation, you will save a lot
of compression/decompression time this way :-).


---------------------

For more information about JPEG in general or the free JPEG software in
particular, contact the Independent JPEG Group at [e-mail].

--
                        tom lane
                        organizer, Independent JPEG Group
Internet: [e-mail]        BITNET: tgl%cs.cmu.edu@carnegie